These nodes rendering into Text nodes in the DOM.

There is a special case when a string is a direct child of a host
node. In that case, we won't reconcile it as a child fiber. In
terms of fibers, it is terminal. However, the host config special
cases it.

It is kind of unfortunate that we have to special case this kind
of child in the HostConfig. It would be nice to unify this with
other types of child instances. Text nodes have some weird special
cases, but those special cases tend to *vary* by environment.
They're not the same special cases so not sure how valuable it is
to have a special protocol and special types for it.

When the feature flag is on, we should silence the warning since
we're explicitly testing it. This is needed when running unit
tests with the flag on.

Dropped the unnecessary use of findDOMNode.
Dropped unnecessary arrow functions.
Math.random() -> id counter, since this used to be
non-deterministic which is not ideal for unit tests.

getOriginalKeys() used to rely on implementation details
to scan that the internal data structure maintained its
structure, however, since that is unobservable we don't
need to test the internal data structure itself. We're
already testing refs and dom structure which is the only
observable effect of the reorder.

This needs to be fixed somehow. The reconciler could know if you
are mounting this continuation into the same spot as before and
then clone it. However, if the continuation moves, this info is
lost. We'd try to unmount it in one place and mount the same fiber
in another place.

We'll enable updating of text nodes. To be able to test that we
need the text nodes to be mutable. They're currently just strings
in the Noop renderer so this makes them an object instead.

That exposed a bug in ReactFiberCommitWork for text nodes.

This implements the first step to proper child reconciliation.
It doesn't yet track side-effects like insert/move/delete but has
the main reconciliation algorithm in place.

The goal of this algorithm is to branch early and avoid rechecking those conditions. That leads to some duplications of code.

There are three major branches:

- Reconciling a single child per type.
- Reconciling all children that are in the same slot as before from the beginning.
- Adding remaining children to a temporary Map and reconciling them by scanning the map.

Even when we use the Map strategy we have to scan the linked list to line up "same slot" positions because React, unlike Inferno, can have implicit keys interleaved with explicit keys.

We use this to track the index slot that this Fiber had at
reconciliation time. We will use this for two purposes:

1) We use it to quickly determine if a move is needed.

2) We also use it to model a sparce linked list, since we can have
null/false/undefined in our child set and these take up a slot for
the implicit key.

We don't need to track side-effects for a parent that has never
been mounted before. It will simply inject all its children when
it completes.

When we don't have any previous fibers we can short cut this path
knowing that we will never have any previous child to compare to.

This also ensures that we don't create an empty Map in this case.

When we reconcile children we need to track the deletions that
happen so that we can perf side-effects later as a result. The
data structure is a linked list where the next pointer uses the
nextEffect pointer.

However, we need to store this side-effect list for reuse if we
end up reusing the progressedChild set. That's why I add a
separate first/last pointer into this list so that we can keep it
for later.

This allow us to track what kind of side-effect this was even
though we only have a single linked list for all side-effects.

First clear any progressed deletions for any case where we start
over with the "current" set of children.

Once we've performed a new reconciliation we need to add the
deletions to the side-effect list (which we know is empty because
we just emptied it).

For other effects, instead of just adding a fiber to an effect
list we need to mark it with an update. Then after completion
we add it to the the effect list if it had any effects at all.

This means that we lose the opportunity to control if a fiber
gets added before or after its children but that was already
flawed since we want certain side-effects to happen before others
on a global level.

Instead, we'll do multiple passes through the effect list.

Instead of passing the full list of children every time to
update the host environment, we'll only do inserts/deletes.

We loop over all the placement effects first and then later
we do the rest.

This shortcut had a bug associated with it. If beginWork on this
child returns null, then we don't call completeWork on that fiber.

Since removing this short cut adds another time check, we have to
add a single unit of time in tests to account for the top level
call now taking one more unit.

This was also the only recursive call in all of fiber so it's nice
to get rid of it to guarantee that a flat stack is possible.

We only use the effect list when we reuse our progressed children.
Otherwise it needs to reset to null.

In all other branches, other than bailoutOnLowPriority, we
revisit the children which recreates this list.

We should also not add fibers to their own effect list since it
becomes difficult to perform work on self without touching the
children too. Nothing else does that neither.

Since that means that the root isn't added to an effect list we
need to special case the root.

It is not possible for a child to have a higher priority level
than we're reconciling at, unless we intentionally want to
down-prioritize it.

While we're deleting nodes, we need to call the unmount
life-cycle. However, there is a special case that we don't want
to keep deleting every host node along the way since deleting the
top node is enough.

These happen in the commit phase *before* the setState callback.

Unfortunately, we've lost the previous state at this point since
we've already mutated the instance. This needs to be fixed
somehow.

During the deletion phase we call detachRefs on any deleted refs.

During the insertion/update phase we call attachRef on class
and host components.

Unfortunately, when a ref switches, we are supposed to call all
the unmounts before doing any mounts. This means that we have to
expact the deletion phase to also include updates in case they
need to detach their ref.

This reorganizes the two commit passes so that all host
environment mutations happens before any life-cycles. That means
that the tree is guaranteed to be in a consistent state at that
point so that you can read layout etc.

This also lets us to detach all refs in the same pass so that
when they get invoked with new instances, that happens after it
has been reset.

If we abort work but have some completed, we can bail out if
the shouldComponentUpdate returns true. However, then we have
a tree that is low priority. When we bailout we currently use
the "current" tree in this case. I don't think this is right.
I'm not sure why I did that.

Similarly, when we complete we use the "current" props if we
didn't have pending props to do. However, we should be using
the memoized props of that tree if it is a pending work tree.

Added a unit test that covers these two cases.